Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-172.txt

Text File | 1994-12-08 | 31.9 KB | 779 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 02 Oct 92       Volume 1 : Issue 172

Today's Topics:

    Selecting a line
    What's a good asm reference book?
    Superdrives reading weird IBM disks
    Code to have a VBL watch over the cursor
    Restricting PBCatSearch
    init help
    How to modify SFGet(Put)File buttons.



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

Organization: Carnegie Mellon, Pittsburgh, PA
Date: Fri, 17 Jul 1992 16:50:20 -0400
From: Brian Campbell <[e-mail]>
Subject: Selecting a line

   For a program (a graphical interface for a circuit simulator) that I
am writing in Think C, icons can be connected to each other via a line
which is defined by two points (one in each icon).  For the
Cut/Copy/Paste features, I want to be able to click on a point on a line
in order to select the line as well as the icons connected to it.  Is
there an easy way to do this?  (I guess the question can also be phrased
as: Is there a way to turn a line into an 'entity' ... similar to a
region?).

Thanks in advance.


******************************************************************************
Brian
[e-mail] (until 8/14)
[e-mail] (permanent)

+++++++++++++++++++++++++++

From: [e-mail] (Nicholas Jackiw)
Organization: Whole Earth 'Lectronic Link
Date: Fri, 17 Jul 1992 21:47:52 GMT

In article <[e-mail]> Brian Campbell <[e-mail]> writes:
>   For a program (a graphical interface for a circuit simulator) that I
>am writing in Think C, icons can be connected to each other via a line
>which is defined by two points (one in each icon).  For the
>Cut/Copy/Paste features, I want to be able to click on a point on a line
>in order to select the line as well as the icons connected to it.  Is
>there an easy way to do this?  (I guess the question can also be phrased
>as: Is there a way to turn a line into an 'entity' ... similar to a
>region?).
>
>Thanks in advance.
>
>
>******************************************************************************
>Brian
>[e-mail] (until 8/14)
>[e-mail] (permanent)



This is a repeat of an article I posted last year sometime.
========================================================
This comes up about once a year.  The consensus is that there are two
ways of doing it, each of which has its demagouges.

First, you can do it by an algebraic function.  If you have a line or
a segment running through/between (X1,Y1) and (X2,Y2), and the mouse
is at (Xm,Ym), then the distance from the mouse to
the line or segment is less than k units iff

     [(dQ)(dX)-(dP)(dY)]^2 - k^2(dX^2+dY^2)<0

where dX=X2-X1; dY=Y2-Y1, dP=Xm-X1, and dQ=Ym-Y1.  You can see that the
entire right-hand term (k-square times the sum of the squares of the
deltas) is constant for any given line, and so needs to be computed only
once (when the line is drawn), rather than every time through the selection
loop.  The left-hand term results in three multiplications and one
subtraction, which can be done entirely with integer arithmetic.

[Note: the above comparison assumes you're dealing with a line and not a
segment (i. e. with infinite extension).  Simply check if (Xm,Ym) falls
inside the bounding rect of the segment, if you want to alter it for
segments.]

The advantage of this method is it's blindingly fast.  If you have a lot
of objects, or require speed for other reasons (for instance, if you test
whether an object's hit in your cursor-idle loop as well as in your
mousedown response), it's the best.  Unfortunately, it doesn't generalize
to other object types, so if you support circles, polygons, etc., you'll
need separate math functions for each of them.


The other method is very elegant and general, but comparatively slow.  In
this method, you allocate an offscreen bitmap k units square (where k is
again your general "distance-considered-close-enough-to-hit" constant)
centered
at (Xm,Ym).  Then you begin drawing your objects, from "front" to "back" if
they aren't planar, one at a time, using this miniscule bitmap as your
portBits.   After each object, check if Quickdraw has set to black any of
the bits contained in the bitmap--if so, the last object drawn should be
considered hit.

The advantage of this method is that it relies on Quickdraw to do all
clipping for you, so you don't need to work out any math if you don't want;
and it works equally well regardless of what type of object you draw:
it's a general solution.  On the other hand, quick as Quickdraw may be,
clipping and bit-writing an object will never be as fast as the few
arithmetic operations required by the first solution.  By the time the
trap dispatcher has located your LineTo()'s trap address in this method,
the previous method will already have returned T or F.

It's up to you.  As a fan of the first method,  I'll say that functions or
algorithms for all basic Mac-Draw-ish shapes..circles, ovals, segments, and
arbitrary polygons--are well known, easy to implement, and fast.
- --
                              --- * ---
Nick Jackiw                  [e-mail]   | [e-mail]
Key Curriculum Press, Inc.   Applelink:KEY.EDUSOFT | [phone]
                              --- * ---

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 18 Jul 92 18:56:57 GMT
Organization: U.C. Berkeley Open Computing Facility

In article <[e-mail]> [e-mail] (Nicholas Jackiw) writes:
>The other method is very elegant and general, but comparatively slow.  In
>this method, you allocate an offscreen bitmap k units square (where k is
>again your general "distance-considered-close-enough-to-hit" constant)
>centered
>at (Xm,Ym).  Then you begin drawing your objects, from "front" to "back" if
>they aren't planar, one at a time, using this miniscule bitmap as your
>portBits.   After each object, check if Quickdraw has set to black any of
>the bits contained in the bitmap--if so, the last object drawn should be
>considered hit.

This is a very interesting way to deal with the problem.  I like it, but it
won't really work for large hollow objects.  But for lines and little shapes
like rasins, it is quite nice.  (And probably preferable for the rasin-selection
algorithm.

:-o  Cool man.

- -E. Wylie

+++++++++++++++++++++++++++

From: [e-mail] (Larry Rosenstein)
Organization: Taligent, Inc.
Date: Sun, 19 Jul 1992 00:31:06 GMT

In article <[e-mail]>, [e-mail]
(Elizabeth Wylie) wrote:
>
> In article <[e-mail]> [e-mail] (Nicholas Jackiw) writes:
> >this method, you allocate an offscreen bitmap k units square (where k is
> >again your general "distance-considered-close-enough-to-hit" constant)
> >centered
>
> This is a very interesting way to deal with the problem.  I like it, but it
> won't really work for large hollow objects.  But for lines and little shapes

I don't see whay it wouldn't work for large hollow objects.  An important
detail is that you have to draw the shapes with black rather than whatever
color or pattern they may have on the screen.  So if you have a large
hollow shape and want to detect click on the interior, you need to draw the
interior with black.

Similarlry, if you wanted to detect a click on some text, you may want to
just draw a black rectangle that represents the text's bounding box.
Otherwise the user will have to click right on some black pixel of a
character.

Also, I don't know if you need to have a k unit square bitmap to handle the
close-enough problem.  You can also draw the shapes slightly bigger to
represent the close-enough distance.  Then you don't have to test as many
bits in the offscreen bitmap.


Larry Rosenstein
Taligent, Inc.

[e-mail]

---------------------------

From: [e-mail] (SCOTT I CHASE)
Subject: What's a good asm reference book?
Date: 17 Jul 92 22:54:11 GMT
Organization: Lawrence Berkeley Laboratory - Berkeley, CA, USA

I'm interested in making my first foray into inline assembly code in Think C
5.0.  Is there a standard reference for 68030 assembly programming?  I have
done some assembly programming on my VAX, so I don't need a primer.  Rather
I want something which is thorough and complete documentation of the
instruction set and how to use it.  Any suggestions?

Regards,

- -Scott
- --------------------
Scott I. Chase            "The question seems to be of such a character
[e-mail]        that if I should come to life after my death
                and some mathematician were to tell me that it
                had been definitely settled, I think I would
                immediately drop dead again."      - Vandiver

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 18 Jul 92 19:04:01 GMT
Organization: U.C. Berkeley Open Computing Facility

In article <[e-mail]> [e-mail] writes:
>I'm interested in making my first foray into inline assembly code in Think C
>5.0.  Is there a standard reference for 68030 assembly programming?  I have
>done some assembly programming on my VAX, so I don't need a primer.  Rather
>I want something which is thorough and complete documentation of the
>instruction set and how to use it.  Any suggestions?
>
>Regards,
>
>-Scott

My favorite is a well-thumbed copy of '68030 Assembly Language Reference' by
Steve Williams.  It is published by Addison Wesley, ISBN 0-201-08876-2.

It goes for about 30 dollars and is about 750 pages.  It covers the 68000,
68010 (yawn), 68020 and 68030.  It describes the differences and how the
caches work.  In the back it actually has some speed comparisons between
some C compiled by MPW and some hand-coded assembly.  This book also covers
the FPU and MMU instructions.

'A must.' -REM "The Voice of Harold"

E. Wylie
(Not associated with any of the above-named entities.  Not even REM)

---------------------------

From: [e-mail] (Paul Craig Tyler)
Subject: Superdrives reading weird IBM disks
Date: 6 Jul 92 04:32:14 GMT
Organization: Basser Dept of Computer Science, University of Sydney, Australia

I would like be able to read an IBM disk (from a non-IBM machine) that has 10
sectors per track rather than 9 sectors.  ie., the formatting information is
the same as an IBM disk but it has an extra sector per track.  I'm wondering
whether it is going to be possible to read this format of disk.  Utilities
like diskcopy read the disk as a 720K (9 sectors/track) disk, ignoring the
10th sector.  Is it possible to access the 10th sector or will it cause some
error because the sector number is illegal?

Any information would be appreciated.  I don't want to spend lots of money
on compilers etc only to find that I can't do this.

- --
Paul Tyler       [e-mail]
University of Sydney, Australia

+++++++++++++++++++++++++++

From: [e-mail] (Steve Christensen)
Date: 18 Jul 92 03:15:03 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Paul Craig Tyler) writes:
>I would like be able to read an IBM disk (from a non-IBM machine) that has 10
>sectors per track rather than 9 sectors.  ie., the formatting information is
>the same as an IBM disk but it has an extra sector per track.  I'm wondering
>whether it is going to be possible to read this format of disk.  Utilities
>like diskcopy read the disk as a 720K (9 sectors/track) disk, ignoring the
>10th sector.  Is it possible to access the 10th sector or will it cause some
>error because the sector number is illegal?

This type of question has been getting a lot of mention lately, so I'll
summarize here.  The floppy disk driver in the Macintosh is designed to
work with 400K GCR, 800K GCR, 720K MFM, and 1440K MFM floppy disks.  It
will deal with no other disk formats.  There are no tables, parameters,
etc., that can be tweaked, nor driver control/status calls that can be
made to change this.  It is not a general purpose floppy driver; it's
only designed to work with formats it knows about.

Several people have asked what it would take to be able to read other
disk formats on the Mac.  I've typically said that you can either write
your own driver or try to hack into the existing one.  In both cases,
I know you'll have a tough time of trying to get this to work, and in
a couple of Mac implementations, it's virtually impossible because of
how the hardware is setup.  Also, Apple has no reason to keep using
the current type of disk controller (it changed from the IWM to the
SWIM in order to support MFM disks), since it will look for lower cost
and/or better feature/performance solutions.

So the bottom line is that there's no support for what you want to do,
it's a tough nut to crack, and if you want to pursue it, you're on
your own...

steve

- --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

---------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: Code to have a VBL watch over the cursor
Date: 15 Jul 92 18:26:32 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <scott.711008283@mcl>, [e-mail] (Scott Bronson) describes
a technique for using a VBL task to watch the modifier keys, so an application
can call WaitNextEvent with a long sleep time and still wake up immediately
to update the cursor when a modifier key changes state.

The idea of using a VBL task is good, but the one of posting an app1 event
to wake up the process is not future-safe. I think Apple now reserves
all the unused "low-level" event types for its own use.

Luckily, under System 7, there is a better way: you can call the Process
Manager routine WakeUpProcess (IM6 page 29-20). And you can do this from
interrupt level.

OK, so you want to remain compatible with System 6. I guess the best approach
is to use the Process Manager call if it's available, otherwise fall back to
posting an app1 event.

I mean, there's never going to be a System 6.1, right...?

Lawrence
USENET DBRA specialist

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Wed, 15 Jul 1992 15:37:18 GMT

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <scott.711008283@mcl>, [e-mail] (Scott Bronson) describes
>a technique for using a VBL task to watch the modifier keys, so an application
>can call WaitNextEvent with a long sleep time and still wake up immediately
>to update the cursor when a modifier key changes state.
>
>The idea of using a VBL task is good, but the one of posting an app1 event
>to wake up the process is not future-safe. I think Apple now reserves
>all the unused "low-level" event types for its own use.

It's worse than that.  As stated in TN180, under Multifinder/Process Manager
there is only one low-level event queue (the place where _PostEvent puts
events), and the events there are always passed to the frontmost process. This
alone disallows the app1Evt technique, since by definition you'd be using it
when your process was not frontmost.

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 19 Jul 92 01:56:06 GMT

In <[e-mail]> [e-mail] (JohnC) writes:

>In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>>In article <scott.711008283@mcl>, [e-mail] (Scott Bronson) describes
>>a technique for using a VBL task to watch the modifier keys, so an application
>>can call WaitNextEvent with a long sleep time and still wake up immediately
>>to update the cursor when a modifier key changes state.
>>
>>The idea of using a VBL task is good, but the one of posting an app1 event
>>to wake up the process is not future-safe. I think Apple now reserves
>>all the unused "low-level" event types for its own use.

>It's worse than that.  As stated in TN180, under Multifinder/Process Manager
>there is only one low-level event queue (the place where _PostEvent puts
>events), and the events there are always passed to the frontmost process. This
>alone disallows the app1Evt technique, since by definition you'd be using it
>when your process was not frontmost.

Not so!  You'll notice that the VBL checks to see if its owning application
is frontmost.  If it is, then it will post the app1evt and check again for
any changes 2 ticks later.  If it isn't frontmost, then my VBL does nothing,
and checks again one second later.

Lawrence's suggestion is a great one (now that he mentions it, I remember
reading the same caveat somewhere), and I'll implement it when I can find time
this week.  I'll be posting the new, future-compatible version to the net
soon, so don't implement VBL cursor-watching in your application yet unless
you are sure that you don't want it to run under System 7.1.  (We know it
works under System 7.0.1 and lower, but it's probably incompatible with
higher system versions right now).

The new version will also have a change suggested by Sigurdur Asgeirsson.

    - Scott

---------------------------

From: [e-mail] (Michael Byrne)
Subject: Restricting PBCatSearch
Date: 17 Jul 92 06:03:07 GMT
Organization: College of Computing

Okay, I must be missing something.  Every time I call PBCatSearch,
it searches the entire volume--but I don't want the entire volume.
For example, if I tell PBCatSearch to find all 'TEXT' files in
a particular folder (and all its subfolders), it still searches the
entire disk for 'TEXT' files, which in my case means it finds a
zillion files--I only want it to find about ten.

I'm setting the ioVRefNum to the working directory number of
the directory I want searched--isn't that how it's supposed to work?
Or does PBCatSearch *always* search the entire volume?

- -------------------------------------------------------------
Mike Byrne                               [e-mail]
Grad student in Psychology/Cognitive Science
25947 GA Tech Station, Atlanta, GA 30332

- ----->>>>    "Only the mediocre are always at their best."


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 17 Jul 92 19:04:56 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail] (Michael
Byrne) writes:
>
> Okay, I must be missing something.  Every time I call PBCatSearch,
> it searches the entire volume--but I don't want the entire volume.
> For example, if I tell PBCatSearch to find all 'TEXT' files in
> a particular folder (and all its subfolders), it still searches the
> entire disk for 'TEXT' files, which in my case means it finds a
> zillion files--I only want it to find about ten.
>
> I'm setting the ioVRefNum to the working directory number of
> the directory I want searched--isn't that how it's supposed to work?
> Or does PBCatSearch *always* search the entire volume?

Yes, that's the way it works. Note the description on page 27-20 if IM VI:
"PBCatSearch looks at all entries in all directories on a volume..." If you want
to limit your searches to a single folder and its sub-folders, use the
techniques shown in Technote #68.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (Doug McNaught)
Organization: California Institute of Technology
Date: Sun, 19 Jul 1992 03:55:33 GMT

In article <[e-mail]> [e-mail] (Keith Rollin) writes:

   In article <[e-mail]>, [e-mail] (Michael
   Byrne) writes:
   >
   > Okay, I must be missing something.  Every time I call PBCatSearch,
   > it searches the entire volume--but I don't want the entire volume.
   > For example, if I tell PBCatSearch to find all 'TEXT' files in
   > a particular folder (and all its subfolders), it still searches the
   > entire disk for 'TEXT' files, which in my case means it finds a
   > zillion files--I only want it to find about ten.
   >
   > I'm setting the ioVRefNum to the working directory number of
   > the directory I want searched--isn't that how it's supposed to work?
   > Or does PBCatSearch *always* search the entire volume?

   Yes, that's the way it works. Note the description on page 27-20 if IM VI:
   "PBCatSearch looks at all entries in all directories on a volume..." If you want
   to limit your searches to a single folder and its sub-folders, use the
   techniques shown in Technote #68.

 Actually, you can restrict the search to a single directory using the
ioFlParID field of the info record. It's not a recursive search,
though--if you want to search a whole subtree you have to do an
indexed search or call CatSearch for each subdirectory, etc...
- -doug
- --
Doug McNaught              |"Sadder still to watch it die/ Then never to have
[e-mail]      | known it/ For you, the blind who once could see/
[e-mail]     | The bell tolls for thee..." --Neil Peart
  Nobody approves my opinions! Not even me, sometimes. Read at your own risk.

---------------------------

From: [e-mail] (Chinn)
Subject: init help
Date: 19 Jul 92 05:46:47 GMT
Organization: University of California, Santa Barbara

Ok, this is my first attempt at using newgroups so I hope I've posted
this properly.  Anyway I have a couple of questions I was hoping
somebody out there might help me with.
1) I've written an INIT/CDEV.  The CDEV lets the user adjust a
setting of the init so I want to be able to determine if the init was
actually loaded and where in memory it is.  Currently I have the init
save its location in the resource file.  The cdev can then check this
location, look for my flags indicating that the location really has
my init, then modify the variable.  Is there a better way to do this?
2)  I need to force a textedit to start displaying at the line of my
choice.  I thought of TESelview() but it only insures that the given
range is somewhere in the view rect, not necessarily the first line.
Thanks for any info...

Paul Chinn         [e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Pete Resnick)
Organization: University of Illinois at Urbana
Date: Sun, 19 Jul 1992 18:05:49 GMT

[e-mail] (Chinn) writes:

I only have an answer to question 1.

>1) I've written an INIT/CDEV.  The CDEV lets the user adjust a
>setting of the init so I want to be able to determine if the init was
>actually loaded and where in memory it is.  Currently I have the init
>save its location in the resource file.  The cdev can then check this
>location, look for my flags indicating that the location really has
>my init, then modify the variable.  Is there a better way to do this?

Yes. Assuming you are running on System 6.0.5 or better, install a
Gestalt selector which will return the address to your INIT. See
Inside Mac VI for details on how to use the Gestalt Manager.

pr
- --
Pete Resnick             (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

---------------------------

From: [e-mail] (Eric E. Braun)
Subject: How to modify SFGet(Put)File buttons.
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Date: Wed, 15 Jul 1992 15:13:11 GMT

Hi,

How does one go about setting a button title in the standard getfile
and putfile windows?  (Pre System 7)

Thanks in advance.

Eric

- --
- -------------------------------------------------------------------------------
Eric E. Braun                        [e-mail]

+++++++++++++++++++++++++++

From: [e-mail]
Date: 16 Jul 92 00:54:13 GMT
Organization: Queen's University at Kingston


  Have a look at Apple's Sample Code 18.  It demonstrates lots of the things
you want to do with the Standard File dialogs.  Oh yes, check that you've got
the second version (May/90?)--the first version was okay but the second is
much better (I'm not sure who did it.  As I recall, there's no credit).

  Cheers,

.../dave   Dave Charlesworth

+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 16 Jul 92 20:28:15 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
writes:
>
>Have a look at Apple's Sample Code 18. It demonstrates lots of the things
>you want to do with the Standard File dialogs. Oh yes, check that you've got
>the second version (May/90?)--the first version was okay but the second is
>much better (I'm not sure who did it.  As I recall, there's no credit).
>

I did the first version (it was one of my first programs for the Mac). Jim
Reekes, Sound Maven, gave it a bath and released the second version.

However, I don't recall that either version answers the original poster's
question. But I could be wrong.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (David J. Harr)
Organization: The Programmers who say NEE!
Date: Sun, 19 Jul 1992 00:04:40 GMT

As an aside, all you up and coming custom open/save dialog box creators
should be aware of a gotcha in SFPGetFile. It doesn't support tabbing
between text edit items you add to the dialog. I had a custom dialog
wherein the user had several edit text items they could type into in
the dialog. For some reason, you could not tab around then properly.
No matter what I did, I could find no problems in my code. I 'linked
DTS, and they informed me that that was an "Unimplemented feature
that was unlikely to ever be retofitted" to the routine. They suggested
I use the new System 7 routines instead. I would, if my app were to
run under System 7. Anyway, I have never seen that documented anywhere,
so I thought I'd throw it out.

David.

"This is a job for STUPOR DUCK!!" (fanfare).


+++++++++++++++++++++++++++

From: [e-mail] (Keith Rollin)
Date: 19 Jul 92 22:35:38 GMT
Organization: Taligent

In article <[e-mail]>, [e-mail]
(David J. Harr) writes:
>
> As an aside, all you up and coming custom open/save dialog box creators
> should be aware of a gotcha in SFPGetFile. It doesn't support tabbing
> between text edit items you add to the dialog. I had a custom dialog
> wherein the user had several edit text items they could type into in
> the dialog. For some reason, you could not tab around then properly.
> No matter what I did, I could find no problems in my code. I 'linked
> DTS, and they informed me that that was an "Unimplemented feature
> that was unlikely to ever be retofitted" to the routine. They suggested
> I use the new System 7 routines instead. I would, if my app were to
> run under System 7. Anyway, I have never seen that documented anywhere,
> so I thought I'd throw it out.

Could you tell us what you tried? Until I left, I used to be the engineer in DTS
that handled all the Standard File questions. Off the top of my head, I can't
think of anything that would prevent you from adding tabbing. Unless Standard
File is continually setting the editText item (which I don't think it is), you
should be able to do what you want, even if it means munging with the itemH and
editField fields of the dialog record yourself, posting your own mouse down
events, or returning the appropriate item numbers from the dlgHook or
filterProc.

- --
Keith Rollin
Phantom Programmer
Taligent, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (David J. Harr)
Organization: The programmers who say NEE!
Date: Mon, 20 Jul 1992 01:30:15 GMT

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>
>> [my comments about SFPGetFile deleted for brevity]
>
>Could you tell us what you tried? Until I left, I used to be the engineer in DTS
>that handled all the Standard File questions. Off the top of my head, I can't
>think of anything that would prevent you from adding tabbing. Unless Standard
>File is continually setting the editText item (which I don't think it is), you
>should be able to do what you want, even if it means munging with the itemH and
>editField fields of the dialog record yourself, posting your own mouse down
>events, or returning the appropriate item numbers from the dlgHook or
>filterProc.
>
>--
>Keith Rollin
>Phantom Programmer
>Taligent, Inc.
>

OK, I had about eight edittext items in the dialog. When you tried to tab
among them, the system would only select as many characters as were in the
lowest numbered edittext item. For example, if the first field had only
three letters in it and the second field had seven, it would only select
the first three letters in the second field. I said to myself "Self, this
is no problem, I'll just write a custom filter proc, and if the key event
is a tab, then I'll just select the entire edittext field by brute force
by checking the editField and then doing a SelIText on the whole mess."
Well, that was a good idea, but it turns out there is NO WAY to get a tab
keypress out of SFPGetFile. I even used a DLOG resource number other than
- -4000 to ensure that I would get keyDown events. However, no matter how I
worked it, I never could get a tab keyDown event from the system, so that
pretty much sunk that theory. Another interesting symptom was that sometimes
the system would "lose its way", ie even though I tabbed, there would be no
edittext item highlighted, and sometimes it would even skip around and have
more than one editext field highlighted at the same time. All in all, very
bizarre behavior.

David.

"My definition of happiness is being famous for your financial ability
 to indulge in every form of excess." -- Calvin.



+++++++++++++++++++++++++++

Organization: Queen's University at Kingston
Date: Sunday, 19 Jul 1992 22:49:42 EDT
From: <[e-mail]>

> However, I don't recall that either version answers the original poster's
> question. But I could be wrong.

Ooops, you're right!  (I could have sworn that was in there.  Well, there are
still lots of good examples of things you'll want to do with SF*File.  I hope
DTS has the time to add to the Sample Code because I've found them useful.)

.../dave   Dave Charlesworth

---------------------------

End of C.S.M.P. Digest
**********************